你好，我是leo。在微服务框架的系统中，一个常见问题是分布式事务的一致性。典型的业务场景是：微服务A增删改数据，微服务B也要增删改数据，两个微服务分别修改自己的数据，但要保证事务。

分布式事务的实现方案有很多，XA、TCC、本地消息表、事务消息等，本篇文章中leo详细聊聊用本地消息表的4种方案和实现细节。

本地消息表的思路是用最终一致性代替强一致性，一种经典的实现方式是：

这个方案可以确保微服务A发送的消息不会丢失，并且发送失败有重试机制确保能发送成功。但因为发送消息强依赖定时任务，所以有个明显的缺点：

由于方案一真正发送消息是在定时任务中发送的，发送频率取决于定时任务，这一点可以进一步优化，在数据库事务完成之后，马上发送消息，而定时任务的功能退化为重试发送之前失败的消息。如下图： 增加红色字体的步骤，这个步骤发送失败的消息才会在定时任务里重新发送，定时任务是兜底的，保证微服务A不会漏发消息。

方案二相比方案一，AB两个微服务的数据一致性时效性提升了，而且对定时任务的依赖减少了，定时任务的频率可以低一点，甚至可以在发送失败情况极少的情况下不要定时任务，改为人工重试发送消息。leo认为，方案二比较适合发送消息的数据量不会过大，发送频率不是非常频繁的业务场景。

无论是方案一和方案二，都会保存全量的消息数据，这可以保证消息在发送环节不会丢，不会漏，但是如果发送的消息量级很大，频繁地读写消息表，对数据库的性能也有一定影响。从这一点出发，可以用另一种方案来实现本地消息表

方案三的思路是本地消息表只保存发送失败的消息，不保存发送成功的消息。如下图： 在这个方案中，数据库事务只处理业务数据，不保存消息数据。事务提交后马上发送消息，一旦发送失败，把失败的消息保存到消息表中，后续由定时任务重试发送。

方案三的优点是：在微服务A正常运行情况下，该发送的消息不会丢失，消息表的数据量很少，读写也不会很频繁，缺点也显而易见，在极端情况下，如果数据库事务提交后刚好服务挂了，没来得及发送消息，那么消息会丢失。另外，保存失败消息时如果服务挂了，消息也会丢失。

方案三重点关注发送失败的消息，数据量较轻，但牺牲了一点可靠性，leo认为比较适合对服务可靠性要求不高的场景。

从方案三的缺点我们可以进一步思考，既然存在消息丢失的风险，那么是不是可以把保存失败消息这个步骤放在数据库事务中呢？

这个方案把发送消息和保存失败消息的步骤放在数据库事务中，即使发送失败了，消息可以保证不丢失，后续由定时任务重试发送消息。

方案四最大的特点是在数据库事务中发送消息，这会带来几个问题：

所以方案四比较适合对系统性能要求不高，并且对两个微服务业务逻辑处理顺序没有要求的场景。

以上，leo总结了4种通过本地消息表来实现分布式事务一致性的方案，核心思路都是通过MQ来实现分布式事务的最终一致性，区别在于对发送的消息如何管理。每种方案都有适用的场景，需要根据实际业务情况来选择使用。